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Abstract 



Software used to produce visual beauty is usually created with imperative programming languages 
and is typically unbeautiful itself. One fundamental reason for this situation is that these languages 
reflect the underlying discreteness and sequentiality of the computers that run them. The essential nature 
of what an image is becomes muddled with details of how to display it on a computer. We can, however, 
generate beautiful images with beautiful programs, by making a shift of programming paradigm, from 
doing to being. This claim is illustrated by many examples expressed in Pan, an image synthesis language 
with a freely available optimizing compiler. 



Visual artwork and program source code typically have very different properties, appealing to different 
modes of perception and comprehension. Art is usually percieved first as a whole and then dissected into 
parts for more detailed examination. Programs, on the other hand, are usually perceived in pieces from the 
beginning, as sequences of small operations, acting on one datum at a time. It is only after patient and 
repeated examination, internalization, and creative reconstruction that the whole emerges. (This difference 
has been noted for images vs language in general and written language in particular. See especially |[T6ll .) 

Why point out this contrast? Is it of any harm that reading a program is so unlike viewing an artwork? 
After all, programs are meant to be understood and acted on by unfeeling, sequential machines, right? 
Not entirely. They also exist for humans to express ideas with clarity, to illuminate and inspire, and to 
be combined with other such idea expressions for forming richer results. To serve these human purposes, 
programs should be expressed as close as possible to the essence of the underlying ideas, stripping away 
incidental artifacts of the machines on which they are intended to execute. 

In contrast with the prevailing tendencies of art and programs, some art forms embrace sequentiality 
(comics |fl31 "), and some programming embraces the whole, in which even the smallest pieces of programs 
produce and transform the large and even the infinite. In this paper, I will demonstrate some of this latter 
form of programming in its use to create images. 

In college math, we discover that spaces can have many dimensions, even infinite, and even uncountably 
many dimensions. We learn to talk about spaces of functions. Every "point" in such a space is an infinite 
thing, and yet, once accustomed, we can play with several of them at once, measuring distance between 



1 Introduction 



them, etc. This is a beautiful and awe-inspiring idea, even a brush with the Divine. It is an invitation to 
"hold Infinity in the palm of your hand," in the words of William Blake. 

When conventional programming is applied to image production, the beauty is almost all in the display, 
very little in the program. I think that the causes for this situation are deeply rooted, and are as described by 
John Backus in his 1977 Turing Award lecture: 

Conventional programming languages are growing ever more enormous, but not stronger. 
Inherent defects at the most basic level cause them to be both fat and weak: their primitive 
word-at-a-time style of programming inherited from their common ancestor-the von Neumann 
computer, their close coupling of semantics to state transitions, their division of programming 
into a world of expressions and a world of statements, their inability to effectively use pow- 
erful combining forms for building new programs from existing ones, and their lack of useful 
mathematical properties for reasoning about programs. @ 

Backus then went on to explore the harmful properties of "von Neumann" programming languages (i.e., 
ones that closely follow the principles of the sequential computer, pioneered by John von Neumann), and 
to offer an alternative, functional programming, drawing a compelling contrast between the two styles. 
Although his Turing lecture was given nearly 25 years ago, the practice of programming continues to be 
dominated by the "primitive word-at-a-time" style that Backus decried. I hope to persuade you that this 
need not be the case in image synthesis, but rather that beautiful images may be formed with beautiful 
programs. 

This paper presents and illustrates an approach to the programming of image synthesis and transfor- 
mation that is far removed from the sequential nature of the underlying computer architecture. Unlike 
the conventional approach, ideal images are described and manipulated directly. Even the smallest sub- 
expressions create and manipulate entire infinite images. The task of turning the described ideal images into 
finite and discrete output for computer screen or paper is entirely automated, and so does not compromise 
the simplicity, clarity, and perhaps most importantly, the composability of the image programs. 

The language used in this paper is implemented as a freely available optimizing compiler whose work- 
ings are described in |)6]| . It produces not just static pictures as shown here, but fast interactive images. I 
encourage you to visit the web site^j peruse the image gallery, download and play with precompiled inter- 
active images, and then use the language and compiler to create your own examples. 

Concretely, the contributions of this work are as follows: 

• A strikingly simple but precise model for resolution-independent images of any type, fitting neatly 
into modern typed functional languages. 

• Within this model, precise and simple definitions for a library of useful image building blocks. 

• Demonstration that the simple model is capable of producing a wide range of visually interesting 
images. 



2 What is an "Image"? 

When languages are given meaning precisely, it is often by being based on a precise mathematical model. 
A good model strips away incidental details, leaving the essence behind. A first question to consider then is 
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what is a good model for images, that is, what is the essence of "image"! 

One natural temptation is to confuse the essential notion with a familiar concrete embodiment. For 
instance, an artist or art lover might consider "image" to mean a painting or drawing, rectangular in shape, 
preferably framed. A photographer might come to think of images as photographic prints, or wall-projected 
photographic slides. A computer user or programmer might say that an image is the contents of a file using 
any of a number of formats, e.g., JPEG or PNG. 

All of these candidates for the notion of an image carry excess baggage that comes from particular 
technologies of image production, storage or use. In extracting an essential notion of image, let's try to strip 
away these incidental artifacts]^] 

• Drop the requirement of rectangularity, allowing images to have any shape at all. Circular or oval 
matting is already a hint that many pictures feel uncomfortable inside rectangular frames. 

• Drop the assumption of finiteness. Most representational pictures are finitely-cropped versions of a 
much larger scene, which the artist invites the viewer to imagine. This larger scene is an image as 
well, whether or not it is ever rendered physically. That larger scene may itself be part of a still larger 
one, and so on. Consider a piece of fruit, in a bowl, on a table, in the kitchen, in a house, on a hill, at 
the foot of a mountain range, in a far-away country, and so on. 

• Drop the discreteness inherent in most computer-based and photographic image representations. Those 
discrete images are generally mere approximations of an underlying continuous image. (In other 
words, essential images are infinite in resolution.) 

Saying that rectangularity, finiteness, and discreteness are all technological artifacts, rather than essential 
properties of images, is not to judge them unimportant. Artists, photographers and graphic designers are 
craftspeople enough not only to cope with these artifacts, but also to exploit them in creative ways, such as 
when the cropping of a picture imparts a feeling of confinement or of openness. 

I propose the following as an essential notion of "image": an assignment of a color to every point in 
infinite, continuous, two-dimensional, Euclidean space. We will want to compose images out of simpler 
ones, so it will be useful to accommodate the desire for finite, though usually non-rectangular, images. A 
simple trick suffices: allow colors to have the property of partial opacity, ranging from fully transparent 
to fully opaque. A "finite image" then is simply one that is fully transparent outside of a finitely bounded 
region of space. Images may then be composed in layers, as illustrated in many examples throughout this 
paper. Partially transparent colors allow lower layers to show through, mixing with upper layers. 

Infinity of extent and of resolution support two dual desires of an image's observer. Infinity of extent 
allows the observer to "zoom out", or step back from an image, getting more and more of the big picture, 
while losing the details. Infinity of resolution allows the observer to zoom in, or step closer, getting more 
and more detail while losing sight altogether of areas outside of the area of focus. 

3 Expressing functions 

I said that an image is an "assignment" of colors to every point in (infinite) two-dimensional ("2D") space. 
Fortunately, mathematics offers a precise and well-studied notion of such assignments, under the name of 

2 I do not want to be dogmatic here, arguing that there is one true essence of "image". Rather, removing these "incidental" 
aspects allows what I find to be a simpler semantic foundation on which to build a language. The rest of the article is offered as 
evidence. Note that this practice of removing inessentials may have no ultimate stopping place short of oblivion. 



"function". One might express the definition of images as followsjj 

type Image = Point — ► Color — first try 

where 

type Point = {Float, Float) — Cartesian coords 

It is useful, however, to generalize the semantic model of images so that the range of an image is not 
necessarily Color, but an arbitrary type. For this reason, Image is really a type constructor, parameterized 
by an arbitrary type c: 

type Image c = Point — > c 



It can also be useful to generalize the domain of images, from points in 2D space to other types (such as 
3D space or points with integer coordinates), but we shall not exploit that generality in this paper. 

Boolean- valued "images" are useful for representing arbitrarily complex spatial regions (or "point sets") 
for complex image masking. This interpretation is just the usual identification between sets and characteris- 
tic functions: 

type Region = Image Bool 
As a first example, FigurefTlshows an infinitely tall vertical strip of unit width, vstrip, as defined belowF] 



vstrip :: Region 

vstrip (x,y) = \x\ < 1/2 

For a slightly more complex example, consider the checkered region shown in Figure [2] The trick is to 
take the floor of the pixel coordinates and test whether the sum is even or odd. Whenever x or y passes an 
integer value, the parity of [x\ + [yj changes. 

checker :: Region 

checker (x,y) = even ([x\ + \_y\) 



Images need not have straight edges and right angles. Figure[3]shows a collection of concentric black&white 
rings. The definition is similar to checker, but uses the distance from the origin to a given point, as computed 
by distO. 

altRings p = even [distO p\ 

3 All definitions in this paper are expressed in Haskell |13|. Comments follow " — ". We take some small liberties with 
notation. As described in |6|, our implementation really uses "expression types" with names like FloatE instead of Float, in order 
to optimize and compile Pan programs into efficient machine code. Operators and functions are overloaded to work on expression 
types where necessary, but a few require special names, such as " == *" and "notE". The definitions used in this paper could, 
however, be used directly as a valid but less efficient implementation. 

4 Each figure shows an origin-centered finite window onto an infinite image and is annotated with the width of the window in 
logical coordinates. For instance, this figure shows the window [—7/2, 7/2] x [—7/2, 7/2] onto the infinite vstrip image. 
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Figure 1 vstrip 
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Figure 2 checker 



The distance-to-origin function is also easy to define: 
distO (x , y) = \/ x 2 + y 2 

It is often more convenient to define images using polar coordinates (p, 9) rather than rectangular coor- 
dinates (x, y). The following definitions are helpful. 

type PolarPoint = (Float, Float) 

fromPolar :: Point — ► PolarPoint 
toPolar :: PolarPoint — ► Point 
fromPolar(p, 9) = (p ■ cos 9, p ■ sin 9) 
toPolar (x,y)= (distO (x,y), atanlyx) 

Figure [4] shows a "polar checkerboard", defined using polar coordinates. The integer parameter n deter- 
mines the number of alternations, and hence is twice the number of slices]^] (We will see a simpler definition 
of polarChecker in Section[8]) 

polarChecker :: Int — > Region 
polarChecker n = checker o sc o toPolar 
where 

sc(p,9) = (p, 9 ■ fromlnt n/ir) 

For grey-scale images, we can use as "pixel" values in the range in the real interval [0,1]. This constraint 
is not expressible in the type system of our language, but as a reminder, we introduce the type synonym Frac: 



5 The "o" operator is function composition; and fromlnt turns an integer into some other type, here Float. 
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type Frac = Float — In [0, 1] 

Figure [5] shows a wavy grey-scale image that shifts smoothly between white (zero) and black (one) in 
concentric rings. 

wavDist :: Image Frac 

wavDist p = (1 + cos (ir ■ distO p)) / 2 



4 Colors 

Pan colors are quadruples of real numbers in [0, 1], with the first three components for blue, green, and red 
(BGR) components, and the last for transparency ("alpha"): 

type Color = {Frac, Frac, Frac, Frac) — BGRA 

The blue, green, and red components will have alpha multiplied in already, and so must less than or 
equal to alpha (i.e., we are using "pre-multiplied alpha" |[T8l ). Given this constraint, there is exactly one 
fully transparent color: 

invisible = (0, 0, 0, 0) 
We are now in a position to define some familiar (completely opaque) colors: 



red = (0, 0, 1, 1) 
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Figure 5 wavDist 



[width — 1] 



Figure 6 bilerpBRB W 



green = (0, 1, 0, 1) 



It is often useful to interpolate ("lerp") between colors, to create a smooth transition through space or 
time. This is the purpose of lerpC w c\ c 2 . The first parameter w is a fraction, indicating the relative weight 
of the color c\. The weight assigned to the second color c 2 is 1 — w: 

lerpC :: Frac — ► Color — ► Color — ► Color 

lerpC w (&i, 0i, n, oi ) (& 2 , ff2, r 2 , a 2 ) = (ft &i &2, ft 9i 92, h n r 2 , ft ai a 2 ) 
where 

/i X\ X2 = W ■ X\ + (1 — w) ■ X2 

With lerpC, we can define other useful functions, e.g., 

lighten, darken :: Fraction — > Color — > Color 
lighten x c = lerpC x c white 
darken x c = lerpC x c black 

It is also easy to extend color interpolation to two dimensions, by making three applications of lin- 
ear interpolation-two horizontal and one vertical. Figure [6] illustrates this operation, and is centered at 
(1/2,1/2) rather than the origin. 

bilerpBRBW = bilerpC black red blue white 



bilerpC r.Color — > Color — > Color — > Color — > (Frac, Frac) — ► Color 
bilerpC 11 Ir ul ur (dx, dy) = lerpC dy (lerpC dx 11 Ir) (lerpC dx ul ur) 



Because of the type invariant on colors, this definition only makes sense if dx and dy fall in the interval 



A operation similar to lerpC is color overlay, which will be used in the next section to define image 
overlay. The result is a blend of the two colors, depending on the opacity of the top (first) color. A full 
discussion of this definition can be found in |[T8l : 

(bi, ft, n, 01) 'overC' (b 2 , g 2 , r 2 , a 2 ) = (h h b 2 , h g 1 g 2 , h n r 2 , h a x a 2 ) 
where 

hx\x 2 = x\ + (1 - a\) ■ x 2 

(Note the use of backquotes to turn the name overC into an infix operator.) Not surprisingly, color- 
valued images are of particular interest, so we'll use a convenient abbreviation: 

type ImageC = Image Color 



Many image operations result from pointwise application of operations on one or more values. For example, 
the overlay of one image on top of another can be defined in terms of overC : 

over :: ImageC — > ImageC — * ImageC 
(top l over l bot) p = top p l overC l bot p 

This commonly arising pattern is supported by a family of "lifting" functionalsp] 



lifti :: (a -> b) -» (p -> a) -> (p -> b) 

lift 2 :: (a ->■ b c) -» (p ->■ a) -> (p ->■ 6) ->■ (p c) 

H/fe :: (a -> 6 c -> d) -> (p -> a) -> (p -> 6) ->• (p ->• c) -> (p -> d) 

lifhhfip =h(f 1 p) 

Hjh hfifcp = h (/i p) (/ 2 p) 

lifhhhf 2 hp = h(hp) (hp) (hp) 



Then ot>er = overC. 

Other examples of pointwise lifting includes selection (cond) and interpolation (lerpl) between two 



[0,1]. 



5 Pointwise lifting 




cond 
cond 



Image Bool 
lifts (A a 6 c 



Image c — > Image c 
if a then b else c) 



Image c 



lerpl :: Image Frac — > ImageC — > ImageC — > ImageC 
lerpl =lift3 lerpC 



6 For intuition, think of p as Point, so that p — *• a = Image a and similarly for b, c, d. 

7 In a call-by-value language, conrf would need to be denned differently, in order to avoid unnecessary evaluation. 



Zero-ary lifting is already provided by Haskell's const function: 

const :: a — > (p — > a) 
const a p = a 

Given const, we can define the empty image and give convenient names to several opaque, constant-color 
images: 

empty = const invisible 

whitel = const white 

blackl = const black 

redl = const red 



Note that all pointwise-lifted functions are polymorphic over the domain type (not necessarily Point), 
and so could work for ID images (e.g., interpreted as sound), 3D images (sometimes called "solid textures"), 
or ones over discrete or abstract domains as well. 

Figure [7] shows a simple example of image interpolation based on the examples in Figures [5] |2j and [4] 
Since lerpl works on color images, we must first color the region arguments. 

bwlm, bylm :: Region — ► ImageC 

bwlm reg = cond reg blackl whitel 
bylm reg = cond reg bluel yellowl 

As a simpler example, Figure [8] interpolates between blue and yellow, and will be useful in several later 
examples. 

ybRings = lerpl wavDist bluel yellowl 



6 Spatial transforms 

In computer graphics, spatial transforms are commonly represented by matrices, and hence are restricted 
to special classes like linear, affine, or projective. Application of transformations is implemented as a ma- 
trix/vector multiplication, and composition as matrix/matrix multiplication. In fact, this representation is so 
common that transforms are often thought of as being matrices. A simpler and more general point of view, 
however, is that transforms are simply space-to-space functions. 

type Transform = Point — ► Point 

It is then easy to define the familiar affme transforms: 

type Vector = (Float, Float) 
translateP :: Vector — ► Transform 
translateP (dx, dy) (x,y) = (x + dx, y + dy) 



Figure 7 i er pj W avDist(bwIm {jpolar Checker 10)) lwidt h = ioi 

(bylm checker) Figure 8 ybRings 



scaleP :: Vector — > Transform 

scaleP (sx, sy) (x,y) = (sx • x, sy ■ y) 

uscaleP :: Float — > Transform — uniform 
uscaleP s = scaleP (s, s) 

rotateP :: Float — > Transform 

rotateP 9 (x, y) = {x ■ cos 6 — y ■ sin 8 , y ■ cos 0 + x ■ sin 9) 

By definition, transforms map points to points. Can we "apply" them, in some sense, to map images into 
transformed images? 

apply Trans :: Transform — > Image c — > Image c 

A look at the definitions of the Image and Transform types suggests the following simple definition: 

? 

apply Trans xf im = im o xf — wrong 
Figures|9]and 10 show a unit disk udisk and the result of udisk o uscaleP 2, where 



udisk :: Region 

udisk p = distO p < 1 
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Figure 9 udisk 
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Figure 10 udisk o uscaleP 2 



Notice that the uscaZeP-composed udisk is half rather than twice the size of udisk. (Similarly, udisk o translateP (1,0) 
moves udisk to the Ze/f rather than right.) The reason is that uscaleP 2 maps input points to be twice as far 
from the origin, so points have to start out within 1/2 unit of the origin in order for their scaled counterparts 
to be within 1 unit. 

In general, to transform an image, we must inversely transform sample points before feeding them to the 
image being transformed: 

apply Trans xf im = im o xf^ 1 

While this definition is simple and general, it has the serious problem of requiring inversion of arbitrary 
spatial mappings. Not only is it sometimes difficult to construct inverses, but also some interesting mappings 
are many-to-one and hence not invertible. In fact, from an image-centric point-of-view, we only need the 
inverses and not the transforms themselves. For these reasons, we simply construct the transforms in inverted 
form, and do not use apply Trans^ 

Because it can be mentally cumbersome always to think of transforms as functions and transform- 
application as composition, Pan provides a friendly vocabulary of image-transforming functions: 

type Filter c = Image c — > Image c 

translate, scale :: Vector — ► Filter c 
uscale, rotate :: Float — > Filter c 

translate (dx, dy) im = im o translateP (—dx, —dy) 

scale (sx,sy) im = im o scaleP (1/sx, 1/sy) 

uscale s im = im o uscaleP (1/s) 

rotate 9 im = im o rotateP (—0) 

8 Easy invertibility is one of the benefits of restricting transforms to be affine and representing them as matrices. 



In addition to these familiar affine transforms, one can define any other kind of space-to-space function, 
limited only by one's imagination. For instance, here is a "swirling" transform. It takes each point p and 
rotates it about the origin by an amount that depends on the distance from p to the origin. For predictability, 
this transform takes a parameter r that gives the distance at which a point is rotated through a complete 
circle (2ir radians): 

swirlP :: Float — ► Transform 

swirlP r p = rotate {distO p ■ 2 ir / r) p 



swirl : : Float — ► Filter c — Image version 
swirl r im = im o swirlP (— r) 



Applying the swirl effect to vstrip (Figure [TJ defined earlier results in an infinite spiral whose arms thin 
out away from the origin (Figure 111. 

It will be useful to have compact names for transformations of color images: 
type FilterC = Filter Color 



7 Animation 



Just as an image is a function of space, an animation is a function of continuous time. This model is adopted 
from Fran 013, and leads to temporal resolution independence, which allows animations to be transformed 
in time, as easily as images are transformed in space. 



As a simple animation example, Figure 12 shows what swirl does to the half plane xPos given by 



x > 0. We square time to emphasize small and large values of the swirl parameter. 

xPos :: Region 
xPos (x, y) = x > 0 



8 Region algebra 



Boolean images are useful in many situations, and can be thought of as "regions" of space. This interpreta- 
tion is just the usual identification between sets and characteristic functions: 

type Region = Image Bool 



Set operations are useful and easy to define: 

(n), (U), xorR, (\) :: Region — > Region — ► Region 
compR :: Region — ► Region 

universeR, emptyR :: Region 
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Figure 11 swirl 1 vstrip 
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[duration — 2, width = 5] 

Figure 12 At — > swirZ (i 2 ) xPos 



(n) 
(u) 

xorR 
compR 
universeR 
emptyR 
r \ r' 



lifta and 
lift® or 
lifti xor 
lifti not 
const True 
const False 
r n compR r' 



Let's see what we can do with these region operators. First, build an annulus out of our unit disk, given 
an inner radius, by subtracting one disk from another: 

annulus :: Frac — > Region 

annulus inner = udisk \ uscale inner udisk 



Next, make a region consisting of alternating infinite pie wedges (Figure 14 1, which is a simplification 
of Figure [4] 

radReg :: Int — > Region 
radReg n = test o toPolar 
where 

test (r, a) = even [a ■ fromlnt n / tt\ 



Putting these two together, we get Figure [T3] 

wedge Annulus :: Float — > Int — > Region 
wedgeAnnulus inner n = annulus inner n radReg n 
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Figure 13 wedgeAnnulus 0.25 7 Figure 14 radReg n for n = 0, 



The xorR operator is useful for creating op art. For instance, Figure 15 is made from two copies of 
altRings (Figure[3]>, shifted in opposite directions and combined with xorR. 

shiftXor :: Float — > Filter Bool 
shiftXor r reg = reg' r l xorR l reg' (— r) 
where 

reg' d = translate (d,0) reg 
Why stop at two copies of altRings? For any given n, the following definition distributes n copies of 



altRings around a circle of radius r and xors them all together (Figure 16 ). 



xorgon :: Int — > Float — > Region — > Region 
xorgon n r = xorRs {map rf [0 .. n — 1]) 
where 

rf i = translate (fromPolar (r, a)) altRings 
where 

a = fromlnt i ■ 2 ■ tt / fromlnt n 
The function xorRs does for a list of regions what xorR does for two. 

xorRs :: [Region] — > Region 
xorRs = foldr xorR emptyR 

Note also that polarChecker (Figure [4]) can be redefined very simply by applying xorR to altRings 
(Figure [3]) and radReg (Figure [T4]): 

polarChecker n = altRings 'xorR' radReg n 
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Figure 15 shiftXor 2.6 altRings Figure 16 xorgon 8 (7/4) altRings 



Similarly, one could use xorR and a coordinate-swapping filter to redefine checker (Figure [2]) in terms of a 
region with alternating horizontal or vertical slabs, 

One use for regions is to crop a color-valued image: 

crop :: Region — > FilterC 

crop reg im = cond reg im empty 

For instance, the title figures come from cropping ybRings (Figure[8]> with regions produced from wedgeAnnulus 
(left of title) or a swirled wedgeAnnulus (right). 



9 Some polar transforms 

The swirlP function (from Section [6] and used to define swirl) can be somewhat simplified by considering 
points in polar rather than rectangular coordinates 0 

swirlP r = polarXf (A (p, 9) — > (p, 6 + p ■ 2ir / r)) 

Note that 0 changes but p does not. 

The useful function polarXf is defined very simply: 

polarXf :: Transform — > Transform 
polarXf xf = fromPolar o xf o toPolar 



'in polar coordinates, a point p is identified by a pair (p, 8), where p is the distance from the origin and 9 is the angle between 
the positive X axis and the ray emanating fm the origin and passing through p. 
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Figure 17 radlnvert checker 



9.1 Turning things inside out. 

Next, let's consider a polar transform that changes p but not 9. Simply multiplying p by a constant is 



equivalent to uniform scaling (uscale). However, inverting p has a striking effect (Figure 17 1: 



radlnvertP :: Transform 

radlnvertP = polarXf (A (p,9) — * (1/p, #)) 

radlnvert :: Image c — ► Image c 
radlnvert im = im o radlnvertP 



9.2 Radial ripples. 

As another radial (p) transformation, we can multiply p by an amount that oscillates around 1 with a 
given magnitude s, having a given number n of periods as 9 varies from 0 to 2tt. As usual, define an 
image-transforming version as wellp"] 

rippleRadP :: Int — * Float — » Transform 

rippleRadP n s = polarXf $ A (p, 0) — ► (p • (1 + s • sin {fromlnt n ■ 9)), 9) 
rippleRad :: Int — > Float — > Image c — > Image c 
rippleRad n s im = im o rippleRadP n (— s) 



In order to visualize the effect of rippleRad, apply it to ybRings (Figure[8]). The result is Figure 18 



The examples so far have been infinite in size. We can also make finite ones by cropping against a 
region. As a convenience, define cropRad as a function that crops an image to a disk-shaped region of a 
given radius: 

10 The "$" operator is infix, right-associative, low-precedence function application. It often reduces the need for parentheses. 
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Figure 18 rippleRad 8 0.3 ybRings 
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Figure 19 



swirl 8 $ cropRad 

rippleRad 5 0.3$ ybRings 



cropRad :: Float — ► FilterC 
cropRad r = crop {uscale r udisk) 



To make the picture more interesting, let's crop, ripple, then swirl (Figure 19 1 



10 Related Work 



Peter Henderson began the game of functional geometry for image synthesis [9]. Since then there have been 
several other such libraries, including lfT4l[T9l l3l[Tl [81171. None have addressed the general notion of images. 

Gerard Holzmann developed a system called "Pico", which consisted of an editor, a simple language 
for image transformations, and a machine-code generator for fast display. His delightful book shows many 
examples, using photos of Bell Labs employees [10]. Pico's model of images was the discrete rectangular 
array of bytes, which could be interpreted as grey-scale values or other scalar fields. The host language 
appears to have been very primitive, with essentially no abstraction mechanisms. 

John Maeda's "Design by Numbers" (DBN) is another language aimed at simplifying image synthesis, 
sharing with Pan the goals of simplicity and encouragement of creative exploration O. In contrast, the DBN 
language is squarely in the imperative style {doing rather than being). Its programs are lists of commands 
for outputting dots or line segments and changing internal state, with an image emerging as the cumulative 
result. Like Pico, DBN presents a discrete notion of space, partitioned into a finite array of square pixels. 

The Haskell "region server" 021 used characteristic functions to represent regions, in essentially the 
same formulation as Pan (Section [8]). Those regions were not used for visualization, nor were they general- 
ized to range types other than Boolean. Paul Hudak also used regions for graphics ifTTTl . There an algebraic 



data-type represents regions, but an interpretation (semantics) is given by translating to a function from 2D 
space to Booleans. 

In his work on evolution for computer graphics, Karl Sims represented images as Lisp expressions over 
variables with names x, y, and t (adding z for solid textures) ifTTll . He did not exploit Lisp's support for 
higher-order functional programming for composing image functions. 



11 Conclusions 

For the purpose of image synthesis, imperative programming languages (including most object-oriented 
ones) are unpleasantly "low-level" in the sense of Alan Perlis: "A programming language is low level when 
its programs require attention to the irrelevant." 

This paper presents a simple model and high-level functional programming language for images, as 
functions from continuous 2D space to colors, and then tests the expressiveness of this model by means of 
several examples. These examples represent just a hint at what can be done, and are far from exhaustive, 
or even necessarily representative. I hope that readers are inspired to apply their own creativity to generate 
images and animations that look very different from the examples in this paper. 
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